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A/IODELE DE DONNEES COMMUN INCLUANT DES INTERDEPENDANCES DE ZONES. 

Un proc§d6 est d§crit pour g6rer des donn§es k partir 
oune certaine vari6t6 de sources (1.2), chaque source dis- 
posant de sa propre interface de programmation tfapplica- 
tion ou API (3, 4). Une couche de gestion de donn^es (5) qui 
contient des metadonn^es d6crit des entlt6s dans chaque 
source en collationnant les m§tadonn6es et en les pr6sen- 
tant sous forme q§n6rique. Un controleur de vision de ni- 
veau superieur (6) communique avec la couche de gestion . 
de donn6es (5) afin de g§rer les donn6es k partir des diff6- 
rentes sources (1. 2). 
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La presente invention concerne un precede permettant de gerer 
des donn§es a partir d'une certaine variete de sources. II existe des 
situations dans lesquelles des donnees existent dans de multiples 
memoires ou stockages de donnees dont chacune ou chacun dispose de 
5 sa propre interface de programmation d'application (API), laquelle 
interface de programmation d'application est un jeu de fonctions 
disponlbles pour que le programmeur les utilise afin de programmer des 
applications et ou il est souhaitable de disposer de la vision generique 
afferente des donnees d partir des divers stockages. Un exemple typique 

10 de cette situation se rencontre dans le domaine de la t6lephonie, 
domaine dans lequel les stockages de donnees sous-jacents 
contiennent une information de tel6phonie telle que des numeros,de 
telephone, des groupes de recherche de ligne et simllaire. 

Typiquement, chaque source de donnees qui peut inclure des 

15 bases de donnees commerciales dispose de sa propre API et il n'est pas 
possible d'assurer un acces gen6rique aux donnees dans le stockage 
sans que les couches superieures disposent d'une connaissance 
specifique de I'API de chaque source de donnees individuelle. Ceci rend 
les couches superieures complexes a mettre en oeuvre. 

20 Un objet de I'invention consiste a alleger ce probleme. 

Conform6ment a la presente invention, on propose un procede 
permettant de g6rer des donnees a partir d'une certaine variete de 
sources, chaque source disposant de sa propre interface de 
programmation d'application ou API, comprenant les etapes consistant a 

25 prevoir une couche de gestion de donnees qui contient des entites de 
description de metadonnees dans chaque source, ladlte couche de 
gestion de donnees collationnant lesdites metadonnees et les presentant 
sous forme generique. et ^ fournir un controleur de vision de niveau 
superieur qui communique avec ladite couche de gestion de donnees 

30 afin de gerer les donnees a partir de differentes sources desdites 
sources. 
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L'invention prevoit par consequent une couche abregee de 
sources de donn^es arbitraires en decrivant un module de donnees 
generique et une API representant le moyen pour acceder aux donnees. 
Le modele de donnees est essentiellement constitue de manlere a 
5 assurer une description des donnees qui soit conviviale pour une 
interface utilisateur. 

L'invention prevoit une description de metadonnees generique et 
une API assocl6e ainsi qu'une representation generique pour des 
interdependances de zones. Les m6tadonnees sont blen entendu des 

10 donnees concernant les donnees. 

L'invention est flexible en ce sens qu'elle permet I'addltion de 
nouveaux types de zone, elle assure la capaclte a decrire des structures 
de donnees davantage complexes ainsi que la capacite a decrire des 
interdependances de zones davantage complexes qu'au prealable. 

15 L'invention peut etre utilis6e par exemple afin d'assurer un acces 

S des bases de donnees produit de Mitel incluant par exemple un 
symbole. IPBX, une nouvelle commande d'appel etc. Elle peut etre mise 
en oeuvre sur un ordinateur d usage general programme de fagon 
appropriee dans ce but. 

20 La pr6sente invention assure par consequent une vision 

generique des donnees a partir de divers stockages de donnees de 
meme qu'elle permet de constituer une infrastructure pour gerer des 
stockages de donnees futurs incluant des bases de donnees 
commerciales. L'invention assure un acces generique aux donnees sans 

25 que les couches sup6rieures aient besoin d'une connaissance sp^cifique 
de I'API de chaque stockage de donnees individuel. 

L'invention sera maintenant decrite de manlere davantage 
detaillee a litre d'exemple seulement par report aux dessins annexes 
parmi iesquels : 

30 la figure 1 est un schema fonctionnel qui illustre la structure du 

modele de donnees conformement a la presente invention ; et 

la figure 2 est un schema qui illustre la representation generique 
d'interd6pendances de zones. 
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Sur la figure 1, le modele generique comprend des sources de 
donnees 1 et 2, chaque source de donnees comportant des interfaces 
respectives 3, 4. Dans cet exemple, la source de donnees 1 est une 
bibliotheque DBA privee et la source de donnees 2 est une base de 
5 donnees SQL. L'interface 3 constitue une API pour la bibliotheque DBA 1 
et un serveur SQL 4 constitue une interface pour la base de donnees 
SQL 2. 

Les interfaces 3 et 4 connmuniquent avec une couche de gestion 
de donnees. laquelle couche de gestion de donnees communique a son 
10 tour avec une couche de vision 6 par Tintermediaire d'une API de gestion 
de donnees 7. UAPI de gestion de donnees 7 constitue un jeu de 
fonctions que le contrdleur de vision de niveau superieur 6 peut utiliser 
pour gerer les donnees en provenance des differentes sources 1, 2. Ces 
fonctions incluent ce qui suit : 
1 5 commande de session (connexion) 

obtention d'une liste de visions 

obtentlon de descriptions de visions 

obtention de descriptions de zones 

transposition d'enumeration (dependant du langage) 
20 obtention de dependances de zones 

fonctions de lecture/ecriture de donnees 

commande de transaction 

La couche de gestion de donnees 5 contient les metadonnees 
pour decrire des entites telles que des produits. des visions, des zones 

25 et des interdependances de zones pour chaque source de donnees 
qu'elle gere. Ces metadonnees sont constituees par les systemes 
d'acces aux bases de donnees sous-jacents pour les diverses sources 
de donnees. La responsabilite essentielle de la couche de gestion de 
donnees consiste a collationner les metadonnees et a les presenter aux 

30 couches superieures sous forme generique. La couche de gestion de 
donnees contient des metadonnees pour decrire les entites qui suivent : 

produits - La couche de gestion de donnees ou DML doit pouvoir 
realiser une differentiation entre les divers types de produits. 
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visions (lignes/rangees) - Une vision est une collection 
lisible/inscriptible de zones a partir d*une base de donnees. Une vision 
contient des zones qui peuvent etre visualisees par un utilisateur de telle 
sorte qu'une application puisse afficher toutes les zones a Tinterieur de la 
5 vision d'une mani6re qui prenne sens pour rutilisateur. Une vision peut 
contenir des zones qui sont a lecture seulement. C'est-a-dire qu'une 
zone peut etre affichee sans etre editee par un utilisateur. 

zones - Une zone est Tentite la plus petite a I'interieur d'une base 
de donn§es. Elle dolt pouvoir etre representee par un type de donnees 
10 natif (c'est-a-dire qu'elle ne peut pas representer une structure - par 
exemple une liste). 

groupes de zones - II s'agit d'un groupage logique de deux zones 
ou plus a rinterieur d'une unique vision (par exemple PLID). Le groupage 
est logique et il n'impose pas un concept d'affichage a interface 
15 utilisateur graphique ou la GUI. 

interd6pendances de zones - II s'agit d'une liste de regies qu'une 
application peut sulvre afin d'assurer un guidage plus important pour un 
utilisateur. 

Les donnees sont representees a I'interieur de la couche de 
20 gestion de donnees selon un format natif. Les couches superieures 
disposent de I'option d'extraire le format natif de zones ou de 
representations sous forme de chaines du format natif. 

Puisque la couche de gestion de donnees gere plusieurs sources 
de donnees. les descriptions des visions et des zones sont specifiques 
25 au produit. Les couches d'acces aux donnees de niveau inferieur (par 
exemple DBA) doivent prevoir une description du type de produit qui est 
gere par ces couches. A ce niveau, la description de produit peut 
simplement etre une valeur d'enumeration de produit. Par exemple : 
types de produit 
30 > SX2000 leger 

> Symbole 

> IPBX 
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La couche de vision 6 procure une vision qui est una collection 
lisible/inscriptible de zones a partir d'une base de donnees. Une vision 
contient des zones qui peuvent etre visionnees par Tutilisateur de telle 
sorte qu'une application puisse afficher toutes les zones a Tinterieur de la 
5 vision d'une nnaniere qui prenne sens pour Tutiiisateur. Une vision peut 
contenir des zones qui sont a lecture seulement. C'est-a-dire qu'une 
zone peut etre affichee sans etre editee par un utilisateur. 

Une vision dispose des attributs qui suivent : 

nom de vision - Une chame qui peut etre affichee dans une GUI 
10 qui identifie la vision. 

ID de vision - Une valeur entiere qui identifie de fagon unique la 
vision a Tinterieur de la base de donnees. 

Une ID de vision n'a pas besoin d'etre unique pour la totalite de la 
couche de gestion de donnees ou DML. 
1 5 type de vision 

liste de zones - Liste de zones contenues a Tinterieur de la vision 

operation supportee 

liste de groupes de zones 

vision parent 
20 vision enfant 

L'attribut de type de vision est une Enumeration extensible de 
types de vision. Une vision doit etre de Tun (et de seulement Tun) des 
types qui suivent : 

normal - Pas I'un des autres. 
25 singleton - Seulement une ligne/rangee de la vision existe a 

rinterieur de la base de donnees (par exemple des options systeme) 

liste comprimee - Une zone cle a rinterieur de la vision peut etre 
modifiee au moyen de la base de donnees sous-jacente lorsque des 
lignes/rangees sont additionnees et supprimees 
30 liste fixe - Aucun enregistrement ne peut etre ni additionne, ni 

supprime. Un nombre fixe d'enregistrements sont alloues par le systeme 
sous-jacent. 
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Un attribut d'operation supportee enumere ('operation autorisee 
pour la vision particuliere. Une vision peut supporter une ou plusieurs 
des operations qui suivent (ou aucune, d'ou ainsi la definition d'une 
vision a lecture seulement) : 
5 insertion (addition) 

suppression 

mise a jour (nnodification) 

Dans certains cas, deux visions peuvent presenter une relation 
parent-enfant. Par exemple, la forme groupe de recherche de ligne dans 
10 le SX2000 de Mitel est constitute par une vision d'information et par une 
vision de donnees. Cette relation est decrite par des attributs de vision 
parent et enfant. Si une vision dispose, d'une vision enfant, alors Tattribut 
de vision enfant contient TID de vision de la vision enfant. Si une vision 
dispose d'une vision parent, alors I'attrlbut de vision parent contient I'lD 
15 de vision de la vision parent. Une vision peut disposer de seulement un 
enfant ou un parent et ne peut pas etre a la fois un enfant et un parent. 

Une zone est I'unlte la plus petite a Tinterieur de la base de 
donnees. Elle doit pouvoir etre repr6sentee par un type de donnees natif. 
Une zone est decrite au moyen des attributs qui suivent : 
20 type de zone 

categorie de zone 
ID de zone 
dimension (longueur) 
valeurs minimum/maximum (Min/Max) 
25 nom de zone 

transposition d'enumeration 
interdependances de zones 

Un attribut de type de zone est une enumeration extensible de 
differents types. Une zone doit etre de Tun (et de seulement Tun) des 
30 types de zone qui suivent : 

chame arbitraire - Pas de limitation sur les caracteres autorises 
chame de telephonic - Seulement les caracteres 0 a 9, * et # sont 
autorises 
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chaine numerique de telephonie - les caracteres 0 a 9, * et # sont 
autorises ou le premier caractere peut etre T suivi par les caracteres 0 a 
9. 

chaTne de noms - Tous les caracteres sont autorises (a-z, A-Z. 0- 
5 9, ! @ # $ % & 0 □ < > .) moyennant les exceptions qui suivent : une 
virgule "," est autorisee et elle est interpretee en tant que delimiteur entre 
le premier nom et le dernier nom et elle n'est pas incluse en tant que 
chatne reelle. 

La barre verticale "|" n'est pas autorisee du fait qu'elle est utilisee 
10 en tant que delimiteur dans z300. La longueur de chame ne peut pas 
exceder le nombre de caracteres maximum defini par I'attribut de 
dimension de zone sans inclure un delimiteur sous forme de virgule. 

chaine alphab6tique - Seulement a-z, A-Z (pas de valours 
numeriques). (Pr6sentement non utilise sur sx2k mais pr6sente ici ^ titre 
15 de coherence). 

chaTne numerique - Seulement les caracteres 0-9 sont autorises. 

chaine alphanumerique - Seulement a-z, A-Z, 0-9. Aucun 
caractere de ponctuation. 

entier 

20 enumeration 

jeu symbolique - Equivalent a des jeux de Pascal. Ce type est 
pour une chaTne basee sur des elements etablis (par exemple des jours 
de la semaine, lundi, mercredi, mardi a jeudi) 

jeu numerique - Equivalent a des jeux de Pascal. Ce type est 
25 pour des valeurs numeriques basees sur des elements etablis (par 
exemple des groupes COR, "2. 4, 5, 19-24, 35"). 

Un attribut de categorie de zone est une liste de zones de bits de 
categories de zone. Une zone peut etre de I'une ou de plusieurs des 
categories de zone qui suivent : 
30 cl6 - La zone est une zone de de dans la ligne/rangee 

lecture/ecriture - La zone peut etre editee par un utllisateur 

lie - La cle qui est liee a une vision parent ou a une vision enfant 
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cle de substitution - la zone est une cle alternative pour des 
operations d*ecriture, 

A rinterieur d'une vision, un groupage de zones peut etre decrit. 
Ces groupages sont des groupes logiques de zones a rinterieur de la 
5 vision. II s'agit d'une indication pour une application du fait que certaines 
zones sont associ6es. Un groupe de zones n'impose pas un apergu et 
une sensation par interface utilisateur graphique ou GUI specifique. Des 
listes de ces groupages de zones sont contenues a rinterieur de la 
description de la vision associee. 
10 Un groupe de zones est constitue par Tattribut qui suit : 

nom de groupe de zones - Une cliaTne qui peut etre affichee par 
une GUI. 

type de groupe 

liste des ID de zones qui sont dans le groupe (ou de pointeurs sur 
1 5 les descriptions de zone) 

Un attribut de type de groupe est une enumeration extensible de 
types de groupe. Un groupe doit etre de Tun des types qui suivent : 

ordonne - L'ordre des ID des zones a rinterieur du groupe 
represente un ordonnancement logique des zones (par exemple PLID 
20 signifie cabinet, etagere, fente, circuit dans cet ordre). II s'agit d'un 
repere pour une application qui peut indiquer un apergu et une sensation 
par GUI. 

non ordonne - L'ordre des zones dans le groupe est sans 
importance. 

25 Les interdependances de zones sont des regies qu'une GUI peut 

souhaiter voir respectees lors de la gestion d'actions utilisateur. 
Lorsqu'un utilisateur est en train d'operer sur une zone, I'application peut 
vouloir avoir connaissance de si les actions de Tutilisateur affectent 
d'autres zones. Dans ce contexte, une zone peut avoir un impact sur 

30 d'autres zones a rinterieur de la meme vision. Uapplication a besoin de 
connaTtre deux choses, c*est-a-dire qu'elle a besoin de connaitre quelles 
autres zones une zone particuliere affecte et quelle action il convient de 
prendre. 
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Afin de decrire des interdependances de zones, chaque zone a 
I'interieur d'une vision peut disposer d*une liste d'impacts de zone. 

Une liste d'impacts de zone contient un ou plusieurs elements 
d'impact de zone. Un element d'impact de zone contient les elements qui 
suivent : 

ID de la zone soumise a impact - L'lD de la zone qui est soumise 
a impact par cette zone 

condition de test - Une valeur d'enumeration de la condition a 
tester pour determiner Taction appropriee. 

contrainte de condition de test - Un pointeur sur une contrainte 
pour le test 

action si "vrai" - L'action a prendre si la condition de test est vraie 
action si parametre "vrai" - Un pointeur sur un parametre pour 
Taction vraie 

action si "faux" - L'action a prendre si ia condition de test est 

fausse 

action si parametre "faux" - Un pointeur sur un parametre pour 
Taction fausse. 

Une enumeration de conditions de test est constituee par ce qui 

suit : 

est nulle - La zone contient une valeur nulle. La contrainte de 
condition de test est nulle. 

est au-dessus de la plage - Ce test peut etre applique pour des 
valeurs d'enumeration ou entieres seulement 

La condition de test est vraie si la valeur de zone est au-dessus 
de la valeur pointee par la contrainte de test. Dans le cas d'une valeur 
d'enumeration. la contrainte de test pointe sur une valeur qui est la plus 
elevee du point de vue de ia position a Tinterieur d'une sous-liste de 
valeurs d'enumeration (c'est-a-dire qu'il ne s'agit pas necessairement de 
Tenumeration de valeur ia plus elevee en termes de valeur entiere). 
Dans le cas d'un entier. la contrainte est une valeur maximum. 

est au-dessous de la plage - Ce test peut etre applique pour des 
valeurs d'enumeration ou entieres seulement. La condition de test est 
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vraie si la valeur de zone est au-dessous de la valeur polntee par la 
contralnte de test. Dans le cas d'une valeur enum^ree, la contralnte de 
test pointe sur une valeur qui est la plus faible du point de vue de la 
position a I'interieur d'une sous-liste de valeurs d'enum6ration (c'est-a- 
5 dire qu'il ne s'agit pas n6cessairement de I'enumeration de valeur la plus 
faible en termes de valeur entiere). Dans le cas d'un entier, la contrainte 
est une valeur minimum. 

est egale - Ce test peut etre applique pour des valeurs 
d'enumeration ou entieres seulement. . La condition de test est vraie si la 
10 valeur de zone est egale ^ la valeur pointee par la contrainte de test 
(pourrait etre utilise pour le type de chaine egalement). 

est dans la liste - Ce test peut etre applique pour des valeurs 
d'enumeration seulement. La condition de test est vraie si la valeur de 
zone est dans la liste pointee par la contrainte de test. 
15 Une enum6ration d'actions est constituee par ce qui suit : 

nuHe - Poursuivre la verification 

pas d'action 

validation - La zone affect§e doit §tre validee 

invalidation - La zone affect6e doit etre invalidee 
20 etabllssement de liste - Peut §tre applique pour des zones 

d'enumeration seulement. Cette action etablit I'affectation de zones pour 
la liste d'enumerations comme pointe par le param6tre d'action associe. 

RAZ de valeur - Mettre a zero la zone affectee 

etablir la valeur - Etablir la valeur de la zone affectee ^ la valeur 
25 pointee par le param6tre d'action associ6. 

etablir la valeur et validation - Etablir la valeur de la zone 
d'affectation a la valeur pointee par le parametre d'action associe et 
valider la zone. 

etablir la valeur et invalidation - Etablir la valeur de la zone 
30 d'affectation a la valeur pointee par le parametre d'action associe et 
invalider la zone. 

On peut par consequent constater que invention propose un 
modele de donnees g6nerique qui pemnet a i'utilisateur d'acceder a de 
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multiples sources de donnees (Jiverses sans la necessite d'une 
connaissance specifique de I'API de chaque source de donnees. 
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REVENDICATIONS 



1. Proc§de de gestion de donnees a partir d'une certaine 
variete de sources (1, 2), chaque source disposant de sa propre 
interface de programmation d'application ou API (3, 4), caract§ris6 en ce 
qu'il comprend les etapes consistant a : 

5 prevoir une couche de gestion de donnees (5) qui contient des 

entites de description dans chaque source, ladite couclie de gestion de 
donnees collationnant des m6tadonnees et les presentant sous forme 
generique ; et 

fournir un controleur de vision de niveau superieur (6) qui 
10 communique avec ladite couche de gestion de donnees (5) afin de gerer 
les donnees a partir de differentes sources desdites sources. 

2. Precede selon la revendication 1 , caracterise en ce que ledit 
controleur de vision (6) communique avec ladite couche de gestion de 
donnees (5) par rintermedlaire d'une API de gestion de donnees 

15 commune (7). 

3. Precede selon la revendication 1, caracterise en ce que 
ladite API de gestion de donnees (7) prevoit un jeu de fonctions 
selectionnees parmi le groupe comprenant : une commande de session, 
une obtention de liste de visions, une obtention de descriptions de 

20 visions, une obtention de descriptions de zones, une transposition 
d'enumeration. une obtention de dependances de zones, des fonctions 
de lecture/ecriture de donnees et une commande de transaction. 

4. Precede selon Tune quelconque des revendications 1 a 3, 
caracterise en ce que ladite couche de gestion de donnees (7) contient 

25 des metadonnees pour decrire des entites selectionnees parmi le groupe 
comprenant : des produits, des visions, des zones, des groupes de 
zones et des interdependences de zones. 

5. Precede selon la revendication 4. caracterise en ce que 
lesdites metadonnees incluent des interd6pendances de zone pour les 

30 donnees sous-jacentes. 
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6. Procede selon la revendication 5. caracterise en ce qu'une 
zone comporte une liste d'impacts de zone a Tinterieur de chaque vision. 

7. Procede de fourniture d'une couche abregee pour une 
certaine variete de sources de donnees (1, 2), caracterise en ce quil 

5 comprend les etapes consistant a foumir une description de 
metadonnees generique et une API associee pour ladite variete de 
sources de donnees et a fournir une representation generique pour des 
jnterd6pendances de zones dans lesdites sources de donnees. 

8. Procede selon la revendication 7, caracterise en ce que 
10 lesdites sources de donnees (1, 2) contiennent des donnees de 

telephonie. 
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Descripteur de zcne pour zone A 



Liste d'impacts de zone * 
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